![[レポート] 診断員と考えるサーバーレスアプリケーションのセキュリティ #devio2022](https://devio2023-media.developers.io/wp-content/uploads/2022/08/ierae_logo_eyecatch.png){kind=logo}
[レポート] 診断員と考えるサーバーレスアプリケーションのセキュリティ #devio2022
こんにちは、AWS事業本部@福岡オフィスのべこみん(@beco_minn)です。
この記事では、2022年7月19日〜29日開催の技術カンファレンス「DevelopersIO 2022」で公開されたセッション動画『診断員と考えるサーバーレスアプリケーションのセキュリティ #devio2022』をレポートします。
「DevelopersIO 2022」では今回ご紹介する動画以外にもたくさんのセッション動画が投稿されました。ご興味のある方は是非ご覧ください。↓
動画
目次
- 00:00 導入
- 04:35 サーバーレスとは？
- 07:21 サーバレスのセキュリティってどうしたらいいんだっけ？
- 12:23 FaaSをセキュアに実装する
- 15:47 クラウドサービスをセキュアに設定する
- 19:33 クラウドサービスをセキュアにつなげる
- 25:11 まとめ
セッション概要
サーバーレス（FaaS）アプリケーションに関し、実際の診断者視点での脆弱性診断の現状と、同社が提供するサービスの内容についてご紹介。
登壇者
- 白木 光達 氏
GMOサイバーセキュリティbyイエラエ株式会社
このセッションで話すこと/話さないこと
話すこと
サーバーレス(FaaS)アプリケーションのセキュリティについて
- 「どうすればいいの？」に実際に診断を実施してる視点で考える
- webやモバイルバックエンドAPI前提
- 実際の脆弱性の話は浅め
- AWS
話さないこと
- CaaS/NoCodeアプリケーションのセキュリティ
- AWS以外の話
- 外部からHTTPアクセスを前提としないサーバレスアプリケーション
レポート
GMOサイバーセキュリティbyイエラエ株式会社のサービス内容
- Web診断
- クラウド診断(Iaas/PaaS, サーバレス, コンテナ)
- Salesforce診断
サーバーレスとは？
[動画内時間] 04:35〜
サーバー管理不要で動作するアプリケーションのこと。以下の特徴を持つ。
- サーバーの運用が不要
- アイドル時に費用がかからない
CNCF(Cloud Native Computing Foundation)では以下のように定義されており、FaaSやBaaSが該当するとの記載あり。
Serverless computing refers to the concept of building and running applications that do not require server management. It describes a finer-grained deployment model where applications, bundled as one or more functions, are uploaded to a platform and then executed, scaled, and billed in response to the exact demand needed at the moment.
「サーバーレス・コンピューティングとは、サーバー管理を必要としないアプリケーションを構築し、実行するという概念である。サーバレス・コンピューティングは、よりきめ細かいデプロイメントモデルを表現している。1つまたは複数の機能がバンドルされたアプリケーション、プラットフォームにアップロードされた後、その時点で必要とされる正確な需要に応じて実行、拡張、課金される。」
AWSのサーバレスサービス
- コンピューティング
- AWS Lambda
- AWS Fargate
- アプリケーション統合
- Amazon EventBridge
- AWS AppSync
- Amazon SQS
- Amazon SNS
- AWS StepFunctions
- Amazon API Gateway
- データストア
- Amazon S3
- Amazon Aurora Serverless
- Amazon DynamoDB
- Amazon RDS Proxy
- その他(セキュリティ)
- Amazon Cognito
サーバレスのセキュリティってどうしたらいいんだっけ？
[動画内時間] 07:21〜
責任共有モデルについて
AWSに責任共有モデルがあるように、サーバレスサービスにも責任共有モデルが存在する。その範囲はIaaSやFaaS、SaaSに応じて異なる。
責任範囲の認識に齟齬があるとセキュリティの盲点につながり、脆弱性を生んでしまう。特に新しいアーキテクチャを採用する際には利用者側の責任範囲をしっかり把握することが大事。
サーバーサイドのWebアプリケーションのセキュリティ
サーバーサイドのWebアプリケーションのセキュリティにおいて、「各要素をセキュアに作る」「各要素をセキュアにつなげる」ことが大事
- 各要素をセキュアに作らないと
- RCE
- SQL Injection
- などのリスクがある
- 各要素をセキュアにつなげないと
- キャッシュ制御不備による情報漏洩
- HTTP Desync Attack
- などのリスクがある
サーバレスサービスを使わない開発（DBやWebサーバーを使うだけ）ではWebアプリケーションをセキュアに作り込む必要があったが、サーバレスサービスを使えばセキュアな設定にするだけで良い。
- サーバレスサービスを用いて「各要素をセキュアに作る」
- 基本はクラウドベンダ側がやってくれる
- 開発者がやること
- FaaSアプリをセキュアに実装する
- クラウドサービスをセキュアに設定する
- サーバレスサービスを用いて「各要素をセキュアにつなげる」
- クラウドサービスをセキュアにつなげる
FaaSをセキュアに実装する
[動画内時間] 12:23〜
FaaSと言えど脆弱性は既存のIaaSやPaaSベースのアプリケーションと同じなので、基本的な対策方法も同じ。
何をすればいいの？
- セキュアコーディング
- ライブラリの既知の脆弱性の検出
- OWASP DependencyCheck や npm audit などの使用
また、以下のようなFaaS特有の部分も対策が必要
- (Lambdaの場合)環境変数にIAMクレデンシャル
- 環境変数が漏洩するような脆弱性のリスクが他環境より大きい
- コード内クレデンシャルの管理
- Secrets Manager や KMS系サービスを利用して機密情報を保護
- クラウドリソースへのアクセス権限が設定可能
- (AWSの場合)Lambda関数の実行ロールのIAM権限を最小限に設定
以下をやれば、さらにFaaSのセキュリティを高めることが可能
- API Gatewayにおけるアクセスログの記録
- Lambdaコード署名
- AWS Singerを利用したコード署名のツール。署名による整合性検証により、信頼できるコードのみがLambdaで実行。
- WAFによる保護の追加
- など
クラウドサービスをセキュアに設定する
[動画内時間] 15:47〜
何をすればいいの？
- 公式ドキュメントやブログ等を読む
- AWSであれば
- CIS Benchmark/AWS Foundational Security Best Practices標準等を活用する
- Security Hub, Trusted Advisor, IAM Access Analyzer等のツールを利用する
- 特にリソースポリシー等のアクセス制御は丁寧に設定する
- 更に深く知りたい場合にはWell-Architectedフレームワークの「セキュリティの柱」を参照すると良い
- アイデンティティとアクセスの管理
- 発見的統制
- インフラストラクチャセキュリティ
- データ保護
- 更に深く知りたい場合にはWell-Architectedフレームワークの「セキュリティの柱」を参照すると良い
よくある脆弱性
『SQS・SNS等のサービスにおけるリソースポリシーの不備』
以下のようなリスクが考えられる。
リソースポリシーの不備により、外部からSQSキューの読み書きやSNSトピックの読み取りが可能
対策は以下
- リソースポリシーの修正
- IAM Access Analyzerの活用(SQS)
クラウドサービスをセキュアにつなげる
[動画内時間] 19:33〜
何をすればいいの？
- 公式ドキュメントを読む
- 「クラウドサービスをセキュアに設定する」で紹介したものと同様
- 特に認可制御に注意してFaaSやBaaSを組み合わせる
- サービス間でデータやヘッダの扱いなどに不整合がないか気をつける
- 最小権限の原則に則る
- Serverless Application Repositoryで信頼できる筆者の作ったテンプレートを参考にする
- (気軽に相談出来るソリューションアーキテクトがいれば)ソリューションアーキテクトに相談する
よくある脆弱性
『API Gatewayにおける認可制御の不備』
※AWS AppSyncでも同様の問題が起こりうる
- 外部から呼び出しを制限すべきAPIに制限がかけられていない
- Admin向けAPIの不正な呼び出し
- WAFで制御したつもりになっていても、あくまで制御出来ているのはCloudFront経由のみ。直接API Gatewayに攻撃されうる。
- .mapファイルからAPI GatewayのURLを取得可能(推測でも可)
- Cognitoオーソライザ + セルフサインアップの問題
- UI上にサインアップ機能が無くても、Cognitoの設定次第でユーザ登録可能
『Cognitoにおけるカスタム属性制御の不備』
Cognitoはユーザに対しカスタムで属性値を付与することが可能。この値が予期せず書き換え可能になっていると、意図しない操作が行われる可能性あり。
以下のようなリスクが考えられる。
- 管理者として操作
- 他テナントの侵害
まとめ
診断員である白木さんが実際に遭遇したケースなどをもとにサーバレスアプリケーションで脆弱性になりうる箇所と対策を具体的に説明されていました。具体的な構成図を使ったセッションだったため、どのような脆弱性があるとどのように攻撃を受けるのかが非常に理解しやすかったです。
セッション内のまとめでは以下が大事であると述べられています。
- 責任共有モデルを意識する
- 各要素をセキュアに作る
- 各要素をセキュアにつなげる
上記のうち私の主業務は開発ではないため、「各要素をセキュアに作る」を強く意識することは普段ありませんが非常に大切なことですね。今後開発を行う際には紹介されているドキュメントを参考にしてみます。
また、GMOサイバーセキュリティbyイエラエ株式会社では、作成されたWebアプリケーションに対してのセキュリティ診断(クラウド診断やウイルス診断)を提供されています。下記弊社フォームからもお問合せして頂けますので、ご興味のある方はお気軽にお問合せください。
以上、べこみんでした。
